Safety Cases: Provenance, Traceability and Delivery

Safety Cases are complex bodies of interdependent evolving information demonstrating safety of some system. The body of material contained therein presents the justification that appropriate safety requirements are met for a system or service including documenting the safety process itself. Safety Case Reports are projections from Safety Cases at a point in time and are usually key deliverables in project lifecycles. Key aspects of a Safety Case and associated reports are to determine and record where supporting evidence arises from provenance, and to track changes in this information as it evolves and changes traceability. In this paper we illustrate these principles in the context of Adelard’s Assurance and Safety Case Environment (ASCE). ASCE is a sophisticated information management system, specifically designed for supporting the development and maintenance of complex interdependent document sets such as Safety and Assurance Cases. We show how information in other sources (for example a Risk Register or Hazard Log) can be interrogated, processed and summarized in a Safety Case, and also how we can track and monitor changes in this information. Finally we discuss reporting requirements in the context of Safety Cases and demonstrate how ASCE supports the automatic generation of production quality Microsoft Word documents, tailored to corporate documentation standards. Introduction The focus of this paper is on how to manage key issues concerning safety cases. Safety cases are (usually) complex evolving interdependent information sets in heterogeneous formats. We provide enough discussion of safety cases and supporting concepts for the paper to stand alone, but for more detailed information of the concept of safety cases the reader is referred to other papers in these proceedings. We first describe a particular approach to developing safety cases as structured arguments. We then describe the ASCE (Assurance and Safety Case Environment) system which has been developed by Adelard over the past decade and how this supports the key concepts of safety cases. Again we cover only enough to allow the paper to stand alone. Further information on ASCE can be found in references 2 & 3. The paper then goes on to elaborate issues in supporting safety cases as dynamic evolving heterogeneous bodies of information, both in managing the evolution of safety cases, probably under a number of management regimes, and on delivery of reports from these safety cases to relevant stakeholders. Finally we illustrate recently implemented features of the ASCE system which provide powerful support for these user-centered problems. Safety Cases and Presentation Style Modern goal based safety regulation typically requires safety arguments (known as safety cases) to be developed and maintained as a primary means of communicating the safety requirements, safety management environment and supporting evidence for safety claims. In the UK, explicit safety cases are required for military systems, the offshore oil industry, rail transport, civil aviation and the nuclear industry. Similar requirements can be found in other industry standards, such as IEC 61508 (which requires a “functional safety assessment”) (ref. 4) and DO 178B (ref. 5) for avionics (which requires an “accomplishment summary”). A recent UK standard covering procurement of safety related military systems (Def Stan 00-56, issue 3 (ref. 1)) describes a safety case as: “...a structured argument, supported by a body of evidence, which provides a compelling, comprehensible and valid case that a system is safe for a given application in a given environment.” Although safety cases are increasingly accepted and mandated for assuring critical systems, the traditional means of production – word processed documents with in-line graphics – has a number of shortcomings. Traditional applications have to be severely stretched for safety case development and the resulting documents are often cumbersome, and can be difficult to construct and review. Moreover, the structure of the safety argument itself is often lost in the volume of paper produced. Stephen Toulmin developed a conceptual framework and graphical notation for representing the structure of an argument in the 1950s. Toulmin (ref. 8) makes a distinction between a “claim or conclusion whose merits we are seeking to establish” and “the facts we appeal to as a foundation for the claim”. Together with the notion of a “warrant” that the facts indeed support the claim, Toulmin developed the following basic graphical notation: